.

iT邦幫忙

2024 iThome 鐵人賽

DAY 5
1

前兩天提到 dbt 將資料庫由上游至下游分成了 staging, intermediate, marts,今天來說說在各階段中模型命名時遇到的難題。

真的不要小看命名,我常常在下載遊戲後,因為平常用的名稱被別人用了,想不到名字就放棄遊玩這款遊戲(???

staging (ref)

stg_[source]__[entity]s.sql 這個基本上就是 staging 模型命名規則的核心,在 staging 其實通常不太會遇到甚麼問題。

我們的 source 包含 backend, ga, gcp 等等,基本上在 BigQuery 有一個原始資料的資料集,就會為其建立一個新的 source。而 entity 的部分就是依循原始資料本來的名字,除非他用的是 camelCase,會在這邊統一命名規則,不太會直接改名,staging 的部分就得盡量比照原始資料,一份原始資料對應一個 staging model,否則之後找資料不容易對應上。

有個例外是可能有多份原始資料對應一個 staging model,像是我們就蠻常遇到這種情況:

同樣定位的資料,由於 API 更新、程式邏輯有調整,將新舊版的資料分成了兩張不同的資料表,這時候或許 union 會是一個解決方法。不確定是否大家都認同這樣的作法,但我認為只要組織內統一口徑一致即可。

intermediate (ref)

int_[entity]s_[verb]s.sql 在 intermediate 中,entity 就不再多做說明,需要討論的大都是後面的 verb。

文件中舉了一些範例:pivotedaggregated_to_userjoinedfanned_out_by_quantityfunnel_created。當時我們花了不少時間討論,仍然只針對比較常用的一些內容有共識,多數的模型還是得作為個案,一一對齊理解,包含要用哪個單字?作為非母語人士,哪個動詞最直觀能聯想到這個模型所進行的轉換,名詞還是動詞要放在前面?要不要加介係詞?

這些在母語環境中,也許不是什麼難事,但在我們團隊中,花了蠻多時間在對齊這部分的理解,為什麼會這麼重視命名呢?

在開發的時候,我們都只能先看到一整排的模型名稱,而不是它們的內容。dbt 在模型命名上,期待達到的效果是--見名如見表。看到名稱馬上能夠知道模型裡面進行了哪些操作,當然可能沒辦法非常詳細,但至少要對於它在整個 pipeline 中上下游的位置,跟哪些模型有關都要能從名稱中看出來,因此命名的重要性就顯現出來了。

marts (ref)

在 marts 中,邏輯就跟 staging 與 intermediate 不太相同了。

首先,dbt 建議 marts 預設建成資料表(table),會運算程式碼並將資料做實體儲存;而 staging, intermediate 預設建成 view,只會先將程式碼做儲存,留下欄位、運算邏輯等,卻不先儲存資料。

這是由於資料庫中分成儲存費用與運算費用,staging, intermediate 中的模型會被多次使用,然而資料的使用者卻不在乎這些模型中的資料,畢竟資料就還未轉換完畢,半成品是不需要做出來占用儲存費用的。

然而 marts 中的資料,很可能會被業務單位直接做使用,或者是在下游的資料分析工具中,透過簡單的篩選後進行使用,需要頻繁地取用這些資料,因此就需要將資料實體儲存於資料庫中,否則每次業務單位更新,上游龐大的原始資料都要重新運算過一遍。

從上面這邊的討論可以知道,marts 是為資料使用端做服務的,因此在架構與命名上,都需要以使用者為主,取名時以業務單位熟悉的方式命名。


除了上面這些內容,我們花了很多力氣釐清之外,還有一個問題點是英文的單複數問題。(認真???)

首先是可數與不可數名詞、以及複數是不規則形的詞彙。

聽說有些人會簡單暴力全部都用有沒有加 S 來做區辨,但就是覺得不太對勁。

就這樣的問題,沒想到居然要花好多時間來釐清…

接著則是複數的位置,簡單以影片相關資料來舉例:

當前平台的影片資訊,我們命名為 dim_videos,dim 為 dimension 的縮寫,通常存放一些事實,像是我們目前有的影片、習題、使用者都算。

而我們也想加入 fct_videos,fct 為 fact 的縮寫,存放歷史資料,而這邊的歷史資料並非使用者使用的歷史,而是平台影片上下架與編輯的歷史,可能影片的描述有調整、標題有更新,每次的變動我們就新增一筆紀錄。

在這兩張表之後,要如何命名使用者觀看影片的表呢?

在苦思許久之後,我們決定使用 fct_user_records_of_videos 來進行使用者觀看紀錄的命名。

回到一開始的問題:S 要加哪裡呢?

表的單位應該是整張表裡的資訊,像是許多使用者,應該就是 users。

所以許多使用者,使用了許多不同影片的各種紀錄,三個單位都要複數嗎?

還是 user_records 應該作為一個名詞,只加在 records 上?

我們最後是採取了 fct_user_records_of_videos 的命名方式,其實也不確定是否為標準答案,有蠻多討論空間。

但如我一再強調的,組織內必須要有共識,不然每次要找表動不動就差個 s 找不到實在是太慘烈了。


上一篇
DAY 4 「這跟文件說的不一樣!」的開始-dbt 導入的實作流程
下一篇
DAY 6 Style 跟文件說的不一樣!談欄位命名
系列文
這跟文件說的不一樣!從 0 到 1 導入 dbt 的實戰甘苦談30
.
圖片
  直播研討會

1 則留言

0
hlb
iT邦新手 5 級 ‧ 2024-11-28 10:48:42

如果叫做 fct_user_video_views 呢?(戰命名啦!)

阿晟 iT邦新手 5 級 ‧ 2024-11-28 11:44:03 檢舉

看起來蠻清爽的
目前想到可能的困擾是不同類型的內容要用不同動詞(名詞?)吧🤔
像是習題、測驗就不太適合用 view,需要另外再思考討論。不過加上動詞也許可以對表格紀錄的內容有更明確的理解,確實也挺不錯的

hlb iT邦新手 5 級 ‧ 2024-11-29 17:06:46 檢舉

用 views 表示觀看紀錄,所以是名詞喔。習題、測驗是指 user 完成測驗嗎?是的話也許用 user_assignment_submissions?

我要留言

立即登入留言